GuardDutyの信頼されたアクセスを有効にした組織のメンバーアカウントで できること/できないこと
はじめに
こんにちは、和田です。
今回はGuardDutyの信頼されたアクセスを有効にした組織で、メンバーアカウントが「できること/できないこと」についてまとめてみます。
信頼されたアクセスとは
Organizations環境内で「信頼されたアクセス」の設定を行うことで、互換性のあるAWSサービスと統合することができます。
それを行うことで、管理アカウントからOrganizations組織内のすべてのアカウントに対して、統合したAWSサービスの利用や設定が一括で行えます。
名前からは機能の詳細がイメージしにくいですが、 Organizations内で特定のAWSサービスの利用や設定が一括で行える機能 と捉えるとよいでしょう。
GuardDutyの信頼されたアクセス
GuadDutyの信頼されたアクセスを有効にすると、組織に存在するアカウントのGuardDutyに対して以下の設定ができます。
- GuardDuty の自動有効化
- すべてのアカウントについて有効にする
- 新しいアカウントについて有効化
- 自動有効化しない
- 保護プラン
- S3 Protection
- すべてのアカウントについて有効にする
- 新しいアカウントについて有効化
- 自動有効化しない
- EKS Audit ログのモニタリング
- すべてのアカウントについて有効にする
- 新しいアカウントについて有効化
- 自動有効化しない
- ランタイムモニタリング
- すべてのアカウントについて有効にする
- 新しいアカウントについて有効化
- 自動有効化しない
- EC2の Malware Protection
- すべてのアカウントについて有効にする
- 新しいアカウントについて有効化
- 自動有効化しない
- RDS ログインイベントモニタリング
- すべてのアカウントについて有効にする
- 新しいアカウントについて有効化
- 自動有効化しない
- Lambda ネットワークアクティビティモニタリング
- すべてのアカウントについて有効にする
- 新しいアカウントについて有効化
- 自動有効化しない
- S3 Protection
GuardDutyおよびGuardDutyの各種保護プランに対して「すべてのアカウントについて有効にする」「新しいアカウントについて有効化」「自動有効化しない」の設定が可能です。
先に結論
先に結論を述べると以下の通りです。
「まあ、そうだろうな」というシンプルな仕様でした。
- 管理アカウント側でGuardDutyの自動有効化設定をしている場合
- メンバーアカウントでGuardDutyの無効化はできない
- メンバーアカウントで各種保護プランの設定変更はできない
- 管理アカウント側でGuardDutyの自動有効化設定をしていない場合
- メンバーアカウントでGuardDutyの有効化/無効化ができる
- メンバーアカウントで各種保護プランの設定変更ができる
この後は、長々と検証の様子を記載しているので結論だけを知りたかった方は、ここでブラウザバックすることを推奨します。
検証してみる
自動有効化しないの場合
まずは管理アカウントより、GuardDutyおよび全てのGuardDutyの各種保護プランに対して「自動有効化しない」の設定にしてみます。
続いて、メンバーアカウントにログインし「GuardDuty」のコンソールを開いてみます。
自動有効化設定をしていないので、まだGuardDutyが有効になっていません。
「今すぐ始める」をクリックしてGuardDutyを有効にしてみます。
特に問題なく、有効化できました。
続いてGuardDutyの「S3 Protection」の設定を変更してみます。
GuardDuty有効化の際に「S3 Protection」の有効になっていますので、これを「無効」にしてみます。
特に問題なく「無効」にできました。
(他の機能についても問題なく「無効」にすることができました。)
続いてGuardDuty自体を「無効」にしてみます。
こちらも問題なく実行できました。
この結果から、管理アカウントからGuardDutyおよび各種保護プランに「自動有効化しない」と選択されている場合、自由に有効化/無効化できる ことがわかりました。
自動有効化する場合
まずは管理アカウントより設定を行います。
GuardDutyおよびS3 Protectionは「すべてのアカウントについて有効にする」を設定し、それ以外は「自動有効化しない」を設定します。
続いて、メンバーアカウントにログインし「GuardDuty」のコンソールを開いてみます。
設定通り、GuardDuty自体は有効になっていました。
続いて、「すべてのアカウントについて有効にする」を設定した「S3 Protection」を開いてみます。
そもそも開けないようですね!つまり設定変更もできなそうです。
このことから、管理アカウントからGuardDuty自体に「すべてのアカウントについて有効にする」と設定した時、「すべてのアカウントについて有効にする」と設定した各種保護プランはメンバーアカウントからは無効化できない ことがわかりました。
まあ、そうなるだろうなという感想です。
続いて、「自動有効化しない」に設定した「Lambda 保護」を開いてみます。
こちらも設定変更できなそうです。
このことから、管理アカウントからGuardDuty自体が「すべてのアカウントについて有効にする」と設定した時、「自動有効化しない」とした各種保護プランはメンバーアカウントからは有効化できない ことがわかりました。
これは意外な仕様ですね!
GuardDuty自体ももちろん無効化できませんでした。
このことから、管理アカウントからGuardDuty自体が「すべてのアカウントについて有効にする」と設定した時、メンバーアカウントからGuardDuty自体を無効化できない ことがわかりました。
現状を整理するとこんな感じです。
(おまけ)
ここまでくると、GuardDuty自体が「自動有効化しない」と設定し、各種保護プランに「すべてのアカウントについて有効にする」のパターンを検証したくなりますね。
やってみます!
メンバーアカウントにログインし「GuardDuty」のコンソールを開いてみます。
GuardDuty自体は有効になっていなそうです。
「今すぐ始める」から有効にしていきます。
無事に有効化できました。
「すべてのアカウントについて有効にする」にした「S3 Protection」を開いてみます。
有効になっていますね。
無効にできるか試してみます。
無効にできました!
GuardDuty自体も無効にできるか試します。
無効にできました!
つまり 管理アカウントからGuardDuty自体に「自動有効化しない」と選択されている場合、各種保護プランの設定に関わらず自由に有効化/無効化できる ことがわかりました。
情報をまとめるとこんな感じでしょうか。
結論、管理アカウントからGuardDuty自体に「自動有効化しない」と選択されている場合、メンバーアカウントで自由に設定変更できる 、 管理アカウントからGuardDuty自体に「すべてのアカウントについて有効にする」と選択されている場合、メンバーアカウントで一切の設定変更ができない と結論づけられます。
管理アカウントからの設定に委ねられるため、フロー図は最終的にこんな感じにまとまりました。
まとめ
今回はGuardDutyの信頼されたアクセスを有効にした組織で、メンバーアカウントが「できること/できないこと」についてまとめてみます。
随分と脱線しましたが、本題に戻りたいと思います。
GuardDutyの信頼されたアクセスを有効にした組織において、
- 管理アカウント側でGuardDutyの自動有効化設定をしている場合
- メンバーアカウントでGuardDutyの無効化はできない
- メンバーアカウントで各種保護プランの設定変更はできない
- 管理アカウント側でGuardDutyの自動有効化設定をしていない場合
- メンバーアカウントでGuardDutyの有効化/無効化ができる
- メンバーアカウントで各種保護プランの設定変更ができる
となります。
一番大事なのは 管理アカウント側でGuardDutyの自動有効化設定をしている場合に、メンバーアカウントで自由に設定の変更ができない という部分だと思います。
厳格な組織の統制が可能になる良い仕様だと思います。
最後に
今回はGuardDutyの信頼されたアクセスを有効にした組織で、メンバーアカウントが「できること/できないこと」についてまとめてみました。
最後までお付き合いいただきありがとうございました。